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An encoding/decoding 
method and apparatus encode 
an input data stream for 
compression purposes, and 
decode the compressed data 
stream for use. The encoding 
process identifies trends in 
the data stream, and stores 
information about the trends in 
an encoded block. The trends 
may include runs, in which 
sequential, corresponding 
groups in the data stream 
have constant values. The 
trends may also include 
ramps, where sequential, 
corresponding components 
in the data stream increase 
or decrease by a linear value. 
An encoded block may also 
be provided to transfer raw 
data. The encoded blocks 
do not store type information 
describing the type of the 
component associated with 
the block. Rather, the decoder . 
infers the type of the components associated with the encoded block according to an original order of components in the data stream, 
the order of the encoded block in the sequence of encoded blocks and a number of the corresponding components encoded by each of 
the preceding encoded blocks. Once the type of the component is determined, the decoder reconstructs the data stream by translating 
the encoded trend information into component values. The encoded data stream is thus decoded without any loss in data accuracy. 
Because type information need not be transferred to the decoder, the size of the encoded block is further reduced, thereby enhancing the 
compression capabilities of the present invention. 
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METHOD AND APPARATUS FOR ENCODING/DECODING A DATA STREAM USING 

INFERENTIAL TECHNIQUES 

FIELD OF THE INVENTION 
5 This invention relates generally to the field of data processing and more specifically to 

a method and apparatus for encoding and decoding a data stream. 

SUMMARY OF THE INVENTION 
An input data stream is encoded for storage, and the encoded data stream is decoded 

10 for processing. The encoding process identifies trends in the data stream, and stores 

information about the trends in an encoded block. The trends may include runs, in which 
sequential, related components in the data stream have constant values. The trends may also 
include ramps, where sequential, related components in the data stream increase or decrease 
linearly, with a constant slope. An encoded block may also be provided to transfer raw data. 

15 The decoder infers the type of the component associated with the encoded block according to 
an original order of components in the data stream, the order of the encoded block in the 
sequence of encoded blocks and a number of the corresponding components encoded by each 
of the preceding encoded blocks. After the type of the component is determined, the decoder 
reconstructs the data stream by translating the encoded trend information into component 

20 values. The encoded data stream is thus decoded without any loss in data accuracy. Because 
type information need not be transferred to the decoder, the size of the encoded block is 
further reduced, thereby enhancing the compression capabilities of the present invention. 

One aspect is a method or system for encoding a data stream comprising a sequence of 
data components. In this aspect, one of the components of data is selected for encoding 

25 responsive to an order of the one of the components within the repetitive series, and 
responsive to a number of each of the components that have been previously encoded, 
wherein the number of each of the components that have previously been encoded varies 
according to identified trends in corresponding components of the repetitive series. 

In another aspect, a method or system of decoding a series of encoded blocks into a 

30 data stream comprising a repetitive series of components of data includes the step of 

associating an encoded block with one of the components in the repetitive series responsive to 
the position of the encoded block within the series of encoded blocks, and further responsive 
to a number of each of the components that have been previously been decoded, wherein the 
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number of each of the components that have previously been decoded may vary according to 
identified trends in corresponding components of the repetitive series. 

According to a further aspect, a method or system of encoding a stream of digitized 
video data comprising a series of pixels, each of the pixels comprising a plurality of ordered 
components, includes the step of selecting one of the components in the series of pixels for 
encoding responsive to an order of the component within the pixel, and responsive to a 
number of each of the components of each of the pixels that have been previously been 
encoded, wherein the number of each of the components that have previously been encoded 
varies according to identified trends in corresponding components of the series of pixels. 

In another aspect, a method of decoding a series of encoded blocks into a stream of 
digitized video data comprising a series of pixels, each of the pixels comprising a plurality of 
ordered components, includes the step of associating each encoded block with one of the 
plurality of ordered components responsive to the order of the each encoded block within the 
series and responsive to a number of the plurality of ordered components that have been 
decoded, wherein the number of the plurality of ordered components may vary responsive to 
identified trends in corresponding components of the series of pixels. 

In another aspect, a system is provided including a device for storing a sequence of 
encoded data blocks encoding a repetitive series of a plurality of types of components. The 
plurality of types of components have a predetermined order. The sequence of encoded data 
blocks include a first plurality of encoded data blocks ordered responsive to the predetermined 
order of the series of the plurality of types of components and a second plurality of encoded 
data blocks, each of the second plurality of encoded data blocks ordered responsive to a 
number of components encoded in previous encoded blocks encoding components of the same 
type and responsive to the predetermined order of the series of the plurality of types of 
components. 

BRIEF DESCRIPTION OF THE DRAWINGS 
In the drawings, 

Figure 1 is a block diagram of source and destination elements in a computer system 
in one embodiment; 

Figure 2 is a block diagram of one embodiment of an encoder in one embodiment; 
Figure 3 A is a block diagram of one embodiment of an encoder; 
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Figure 3B illustrates an example data format of a series of encoded data blocks; 
Figure 4 is a flow diagram illustrating one embodiment of an encoding process; 
Figure 5 is a flow diagram illustrating one embodiment of a decoding process; and 
Figure 6 is a flow diagram illustrating one embodiment of a method for extracting an 
encoded block for the decoding process of Figure 4. 

DETAILED DESCRIPTION 

A technique for encoding and decoding allows a source data stream to be represented 
by a relatively smaller encoded data stream. The encoded data stream may be decoded to 
reconstruct the source data stream without any loss of accuracy. This encoding technique may 
be useful in the art of video processing for transferring video at a rate that allows for real-time 
special effects processing. In addition, this encoding technique may be useful in any data 
transfer operation. For example, this technique also has applicability to other areas besides 
video processing, such as computer design, networking and any system where large amounts 
of data need to be transferred from a source to a destination with accuracy. 

The encoding technique operates by identifying trends in the source data stream and 
representing the trends using associated encoded blocks. A trend may include a run of one 
value, where the value is repeated in multiple, sequential related components of the data 
stream. A trend may also include a ramp of values, where the value of data in one of the 
blocks increases by a fixed amount in sequential related components. Instead of transferring 
the discrete blocks that form the trend to a destination, information describing the trend is 
transferred. For runs, the information includes both a count of the number of sequential 
related components that have the same value, and that value. For ramps, the information 
includes a count of the number of sequential related component whose values differ by a fixed 
amount (i.e, a constant slope), the value of the fixed amount (slope) and the value of the block 
at the starting point of the ramp. The starting point of the ramp is the value of the first 
component in the sequential related components forming the ramp. The destination decodes 
the trend information to reconstruct the data stream with total accuracy. 

The above encoding and decoding techniques may be used to encode and decode data 
streams that include only one type of data. Alternatively, the encoding and decoding 
techniques may be used to encode and decode data streams that include multiple types of data, 
where the data stream is formed by repetitive sequences of the multiple data types. The 
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multiple data types may be, for example, components of digitized video. Alternatively, the 
multiple data types may reflect multiple interlaced data streams from different sources. 
Accordingly, the type of data is not a limiting factor of the invention. 

One example of a data stream that includes repetitive fixed sequences of multiple data 
5 types is a digitized video data stream. Digitized video component ordering may follow any 
standard convention, such as CCIR656 4:2:2, as follows, where time advances left to right, 
left component first): 

CbO, YO, AO, CrO, Yl, Al, Cb2, Y2, A2, Cr2, Y3, A3 

In the above data stream, each pixel is represented by four different types of 

10 component data: two types of chrominance data (Cr and Cb), luminance data (Y) and 
transparency/alpha data (A). As mentioned above, the encoding technique of the present 
invention is capable of identifying trends in sequential related components, for example 
sequential Cr bytes in the data stream. Therefore, if a Cr value is constant for ten sequential 
pixels, when the first of the ten pixels is encoded, the value ten and the Cr value are 

15 transferred in one encoded block. No Cr encoded blocks are transmitted for the next nine 
pixels. Thus, the original order of the received data stream ( Cb, Y, A, Cr, Y, A ) may not be 
retained in the encoded data stream. 

Because there is no fixed order for the encoded data, the decoder must associate 
received encoded blocks with their corresponding components. However, in one embodiment, 

20 the encoded blocks include no information as to the type of component that the block encodes. 
In such an embodiment, the decoder infers the type of each of the encoded blocks based on an 
the order of the fixed sequence of multiple data types in the original data stream and based on 
the number of previously received components of the different types. Thus, the encoder and 
decoder follow an ordering convention. This convention may be either a fixed convention or 

25 may be altered dynamically during operation. The encoding technique permits the decoder to 
assume that it is always receiving the exact type of data that is required to maintain the fixed 
sequence of multiple data types at an output data stream. Removing the need to identify the 
type of data that is transmitted reduces the amounts of control in the encoded block, and 
thereby allows for more of the bus bandwidth to be occupied by data transfers, thereby 

30 increasing the bus bandwidth between the source and the destination. 

For example, referring now to Figure 1, example components of a computer system 10 
for performing the encoding or decoding process includes a source 12 which receives a data 



WO 99/52294 PCT/US99/06865 

-5- 

stream on line 1 1. In one embodiment, the source 12 may be a video and audio I/O subsystem 
and the data stream may be a series of digitized video components ordered according to 
CCIR656 4:2:2 format, although the invention is not limited to any particular form of data 
stream. The source includes an encoder 15 which encodes the input data stream. The encoder 
1 5 may be a computer program executed on a general purpose computer that operates on the 
data stream either as it is received or after it is stored in uncompressed format in storage 
device 16, or alternatively may be implemented in hardware. Although the source and 
destination are shown in the figure as separate machines, they may alternatively be resident on 
a common device. 

Coupled to the source device 12 is a destination device 20. In an example 
embodiment, the destination device may be a digital film workstation, although the invention 
is not limited to any particular type of destination device. The destination device includes at 
least one decoder 25 coupled to at least one processing unit 22. Alternatively, multiple 
processing units in the destination may share one decoder 25 or have dedicated decoders. 

The source transfers encoded data on line 1 7 to the destination 20. According to one 
embodiment, communication between the source 12 and destination 20 is data flow 
controlled. Thus, handshake signals are used to control the flow of data between the source 
and the destination. One method of controlling the data flow between the source and 
destination is described in pending patent application entitled "Apparatus and Method for 
Controlling Transfer of Data Between and Processing of Data by Interconnected Data 
Processing Elements", serial number 08/879,981, filed June 20, 1997 and incorporated herein 
by reference. Various implementations for the interconnect and a protocol for controlling data 
flow over the interconnect are described in: U.S. Patent Application Serial No. 08/879,981; 
U.S. Patent Application entitled "Apparatus and Method for Controlling Transfer of Data 
Between and Processing of Data by Interconnected Data Processing Elements," filed April 3, 
1998, by Craig R. Frink et al.; and U.S. Patent Application entitled "A Packet Protocol for 
Encoding and Decoding Video Data and Data Flow Signals and Devices for Implementing the 
Packet Protocol " filed April 3, 1998 by Craig R. Frink, et al.; and U.S. Patent Application 
entitled "Method and Apparatus for Controlling Data Flow Between Devices Connected by a 
Memory," filed April 3, 1998 by Craig R. Frink, which are hereby incorporated by reference. 
In addition, Direct Memory Access (DMA) techniques, known to those of skill in the art, may 
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be used to transfer the data between the source 12 and destination 20. However, the present 
invention is not limited to any particular data transfer technique. 

The encoder 15 encodes the received data stream into a sequence of encoded blocks. 
The types of encoded blocks include Run code blocks, Ramp code blocks and Raw code 
5 blocks, although in one embodiment multiple different variations of the above three types of 
encoded blocks are provided. Run code blocks are used to encode "runs" of data; i.e., where 
there is a constant value of data for a given component of the data stream for multiple, 
sequential iterations of the component. Ramp code blocks are used to encode a series of 
components when the value of sequential iterations of the component changes at a constant, 

10 non-zero rate. Raw code blocks are used to directly encode components when the sequential 
iterations of the component differ in value and do not have ramp characteristics. 

As mentioned above, this encoding method may be used to encode digitized video 
data, which is comprised of frames each having a predetermined number of lines of pixels in 
each frame, where each frame may be comprised of a number of fields. In one embodiment, 

15 the following control blocks are provided for encoding digitized video, although the present 
invention is not limited to the types of formats of the encoded blocks described below. 

A Run code block is provided for encoding a run of up to 127 values. A Line Run 
code block is provided for encoding a series of lines all having the same component value. A 
Short Raw code block is provided for encoding one to three distinct component values. A 

20 Long Raw code block is provided for encoding between 4 and 255 components. A Raw to 
end code block is provided for encoding a series of components, each of which have different 
values, up until the end of the frame. A Ramp code block is provided for encoding a ramp of 
between four and 126 values. A Lock code block is provided for causing a constant value of 
to be used for the component in a given field. An Unlock code block is provided for releasing 

25 all locked values. 

Other code blocks include an Enable Borders code block for modifying the 
interpretation of alpha values to allow blending to a border of a frame. A Disable Borders 
code block resets the interpretation of alpha values to straight blending between a foreground 
and a background. An End-of-field control block identifies the end of the field within the 

30 frame. A Line Length code block identifies the number of bytes of compressed data that 
represent a complete line. 
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In addition, an Image Header control block is provided, where the image is a frame or 
field, and a frame comprises one or more fields. The Image Header control block is the first 
coding block of a field or frame and provides descriptive information about the field or frame 
that follows. The first two data bytes in the field constitute a flag word defined, in one 
embodiment, as follows: bit 7 (high) of datao = 1 if a frame follows, 0 if a field follows. The 
next two data bytes comprise a 16-bit value that is the total size of the compressed data 
frame/field including the header and all other encoded blocks. This value allows software to 
quickly skip across fields in a stream of RLE compressed data. 

According to one embodiment, each of the encoded blocks includes two or more bytes 
of data. The trend represented by the encoded block is indicated by the value of the first (and 
in some instances the second) byte of the encoded block. Example mappings of byte values to 
code block definitions are provided in Table I below: 



TABLE I: 



Description 


ByteO 


Bytel 


Byte 2 


Byte 3 


Byte 4 


Run 


length 
(1 to 127) 


value 








Short Raw 


length + 128 
(129 to 131) 


value 0 








Ramp 


length + 128 
(132 to 254) 


value 


slope *256 
(high-byte) 


slope *256 
(low-byte) 




Long Raw 


255 


length 
(4 to 255) 


value 0 


value. 




Raw to end 


128 


value 0 


value, 


value? 




Lock 


0 


126 








Unlock 


0 


127 








Enable 
Borders 


255 


3 








Disable 
Borders 


255 


2 








End-of-field 


255 


1 








LineRun 


0 


length + 128 
(129 to 255) 


value 
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I .ineLen* 


0 


length = 3 
(1-125) 


0 


line len 
(high-byte) 


line len 
(low-byte) 


ASCII 
Comment * 


0 


length 
(1-125) 


1 


char 0 




Image 
Header* 


0 


length 
(1-125) 


2 


date 0 




RFU* 


0 


length 
(1-125) 


subcode 
(3-255) 


datao 




Reserved 


0 


0,128 








Reserved 


255 


0 









10 One embodiment of an encoder is shown in Figure 2. The encoder operates as 

follows. As the stream of digitized video data is received at the video data I/O subsystem 12, 
it is apportioned into frames of data. Each frame of data is further apportioned into 
components of Cb, Cr, Y and A components, and stored in storage device 100. The 
components are then selected for encoding in response to the predetermined ordering 

15 convention of the components and the number of components of each type that have already 
been encoded. The number of components of each type that have been encoded at any given 
time may vary according to trends that have been recognized and encoded for each of the 
types. 

Thus, one embodiment of the encoder of Figure 2 includes the following counters: a 
20 Pixelcount 102, a Cbcount, 104, a Ycount 105, an Acount 106 and a Crcount 107. Values 
from the counters are input to select logic 110. Select logic 1 10 outputs a select line to select 
one of the types of components 100 to forward to Encoder 113. The results from Encoder 1 13 
are output as Encoded Block 1 14. 

Referring now to Figure 3 A, a method for encoding an input data stream of digitized 
25 video data received in a Cb, Y0, AO, Cr, Yl, Al format is shown. The process illustrated in 
Figure 3 A is only one example of one method of performing encoding according to the table 
set forth above. Alternative methods may also be implemented within the spirit of the present 
invention. In any of the potential embodiments, the order of encoding of the Cb, Cr, Y and 
Alpha components is determined such that the component type selected for encoding 
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generates the type of encoded block required for reconstructing the data stream in its original 
order. 

In one embodiment, in order to ensure that the appropriate encoded block is generated, 
counters are maintained to monitor the number of Cb, Cr, Y and Alpha values that have 
5 already been encoded. The counters are represented by the values Cbcount, Crcount, Ycount 
and Acount, respectively. The selection of which type of component to encode is thus 
determined in response to the original order of the fixed data stream and the values of the 
counters. 

The process of Figure 3 A is best explained by way of example. Assume that an input 
10 data stream having the following components is received at the source 12: 

CbY A CrY A| Cb Y A CrY A| Cb Y A CrY A| Cb Y A CrY A| Cb Y A CrY A| 

531430431730331 330221421331 6 30 

15 The resulting groupings of components would be: 

Cb: 5 4 3 2 3 
Y: 3333332233 
A: 1010 10 1110 
Cr: 4 7 3 4 6 

20 

The encoded blocks and the associated counter values after each cycle of encoding is 
shown below in Table II: 
Table II: 



cycle 


encoded block 


Cbcount 


Ycount 


Acount 


CrCount 


1 


132,5,-1 


4 








2 


6,3 


4 


4 






3 


131,1,0,1 


4 


4 


3 




4 


131,4,7,3 


4 


6 


3 


3 


5 


131,0,1,0 


4 


6 


6 


3 


6 


2,2 


4 


8 


6 


3 


7 


3,1 


4 


8 


9 


3 


8 


130,4,6 


4 


8 


9 


5 
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cycle 


encoded block 


Cbcount 


Ycount 


Acount 


CrCount 


9 


129,3 


5 


8 


9 


5 


10 


2,3 


5 


10 


9 


5 


11 


129,0 


5 


10 


10 


5 



In Figure 3A, after the digitized video data stream has been received, at step 38 the 
process of encoding the digitized data stream begins by initializing the Ycount, Acount, 
Cbcount and Crcount. In one embodiment, a variable Pixelcount is also used to identify 
which pixel in the data stream is being encoded. At step 38, the Pixelcount variable is 
initialized to a value of one. 

At step 39, the Cbcount is compared against the Pixelcount. If the check at step 39 
indicates that a Cb component has not been encoded for the pixel, at step 40 the Cb 
components are encoded, a code block 45 is generated and the Cbcount is incremented to 
three. In the above example, the first four Cb components form a ramp of four values, starting 
at value 5 with a slope of -1. Thus, the encoded block of 132, 5, -1 is generated. 

If the comparison at step 39 had indicated that a Cb component had already been 
encoded for the pixel, or once the Cb component is encoded, the process continues to step 42 
where it is determined whether the first Y component of the pixel was encoded. In the above 
example, the Y components includes a run of six values of three. Thus, the encoded block 6,3 
is output as coded block 48 and the Ycount is incremented to six. 

If the comparison at step 42 had indicated that the first Y component of the pixel was 
encoded, or after the Y component is encoded at step 46, at step 49 a compare is made 
between the Acount and the Pixelcount to determine if the first Alpha value of the pixel has 
been encoded. In the above example, the first Alpha value has not been encoded, and the 
resultant encoded block 55 is a Short Raw block including values 1,0,1 . The Acount is 
incremented to three. 

At step 52, a comparison is performed between the Pixelcount and the Crcount to 
determine if a Cr component has been encoded for the pixel. If not, the Cr components are 
encoded at step 54 and an encoded block 56 is generated. In the above example, a Short Raw 
block of 4,7,3 is generated, and the Crcount is incremented to three. 

The process proceeds to step 58, where it is determined whether the second Y 
component of the pixel has previously been encoded. If not, encoding is performed at step 60 
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to generate an encoded block 65. In the above example, six Y components have already been 
encoded. Thus, no further encoding of Y components is required for this pixel, and the 
process proceeds to step 66 where the it is determined whether the second Alpha component 
of the pixel had previously been encoded. In the above example, three Alpha components had 
5 previously been encoded, and therefore no further encoding of Alpha values need be 
performed for this pixel. 

At step 72 the Pixelcount is incremented and at step 76 the Pixelcount is compared 
against the maximum number of pixels in the frame. This value will vary depending upon the 
type of frame being encoded. If there are still pixels within the frame to be encoded, the 

10 process continues at step 38, where the Cbcount is compared against the Pixelcount. 

As is evident in the flow diagram of Figure 3 A, encoding is performed on the 
components when the component is needed to form an entire pixel. Continuing with the 
above example, when encoding the second pixel (PixelCount=2), the Cbcount (value 4) , 
Ycount (value 6), Acount (value 3), and Crcount (value 3) indicate that no encoding is needed 

15 for either the Cb, Cr, Y or first Alpha component of pixel two. However, the second Alpha 
component for pixel two has not yet been encoded. Thus, at step 68 the Alpha components 
are encoded to provide a Short Raw encoded block of 129,0. 

At step 72, the Pixelcount is incremented to three. Because a sufficient number of 
components is available to form a third pixel, no encoding is performed for the next pass 

20 through the flow diagram, and the Pixelcount is incremented to four. For the fourth pixel, a 
Cb component need not be encoded because the Cbcount indicates that four components have 
already been encoded. Thus, the next component that is encoded is the Y component, which 
results in a Run encoded block of 2,2. The Ycount is incremented to eight. The Alpha 
components are next encoded, providing a Run encoded block of 3,1, and incrementing the 

25 value of the Acount to nine. The Cr components are next encoded, providing a Short Raw of 
130, 4,6. The Cb components are next encoded, providing a Short Raw encoded block of 129, 
5. The final Y components are next encoded, providing Run encoded block of 2,3 and the 
final Alpha component is encoded, providing the Short Raw encoded block of 129,0. 

Thus, the selection of the type of component to encode is made in response to the 

30 predetermined order of the components, the number of the pixel in the stream that is being 
encoded and the number of each of the components that have previously been encoded. The 
result is a sequence of encoded blocks, each of the encoded blocks associated with one of the 
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components of the original data stream but including no data representing the association. 
Rather, the type of the encoded block may be inferred according to the order of the encoded 
block in the sequence of encoded blocks and a number of components encoded by each of the 
preceding encoded blocks. 
5 The sequence of encoded data blocks generated in the above example is shown in 

Figure 3B stored in a memory 105. Note that each of the encoded data blocks includes an 
encoding indicator 108, indicating a type of encoding, and one or more data fields 109. Note 
that there is no indicator as to the type of component that the block encodes. During the initial 
encoding phase, indicated by line 1 1 1 in Figure 3B, an encoded block for each one of the 

10 types of components is issued according to the predetermined order of the components in the 
input data stream. After the initial encoding phase, because different numbers of each of the 
components were encoded in the initial phase, the order of the types of the conventional 
blocks no longer follows that of the predetermined order of the input data stream. Rather, 
blocks are selected for encoding as they will be needed to reconstruct the data stream in the 

15 original order. 

The encoded data blocks are forwarded to the decoder 25. One embodiment of the 
decoder 25 is shown in Figure 4. The decoder 25 provides an output data stream of 
components having the same order as the original input stream of components received by the 
encoder 12. As encoded data blocks 1 14 are forwarded to the decoder, the decoder assumes 

20 that an encoded data block received from the encoder 12 encodes the type of component 

required for the decoder to maintain the order of the output data stream. Therefore, each time 
that the decoder decodes one of the encoded blocks using decode logic 115, one of the 
decoded components is output to the output data stream. 

Because the encoded blocks may store more than one value for the associated 

25 component, each decoded value that is not output in the data stream is stored in a 'bucket' for 
the associated component. Thus, the decoder 25 includes a Cr bucket 1 1 6, a Y bucket 1 1 8, an 
A bucket 120 and a Cr bucket 122. The bucket may be, for example, a storage device such as 
a First-In-First-Out (FIFO) buffer. Counts are maintained for each of the buckets. Cbcount 
130 indicates how many Cb values are available to be output to the output data stream, 

30 Ycount 1 32 indicates how many Y values are available to be output to the output data stream, 
Acount 134 indicates how many Alpha values are available to be output to the output data 



WO 99/52294 PCT/US99/06865 

-13- 

stream and Crcount 136 indicates how many Cr values are available to be output to the output 
data stream. 

Because the component buckets 1 16-122 store values for the components, the decoder 
does not always need to decode a block in order to output a component to the output data 
5 stream. The sources for the output data stream include the Encoded block 1 14, the Cr bucket 
1 16, the Y bucket 1 18, the A bucket 120 and the Cr bucket 122. 

The selection of a source for a component in the output data stream is controlled by 
select logic 128. Select logic 128 receives, as input, the Cbcount 130, Ycount 132, Acount 
134 and Crcount 136 as well as a Position value 126. The Position value is used to track the 
10 position of the component within the pixel that is being output into the data stream. 

When the decoder needs to output a particular type of component in the output data 
stream, the bucket associated with that particular type of component is first examined to 
determine if there are any previously decoded values stored for that component. If the counts 
130-136 indicate that there are values stored in the bucket, the appropriate value is retrieved 
15 from the bucket and output into the output data stream and the count is decremented. 

Accordingly, the decoder decodes encoded blocks for a component when the count indicates 
that the bucket for that component is empty. 

Referring now to Figure 5, an example process of such a decoding method for use in 
decoding digitized video is shown. The variables that are used in the example decoding 
20 process of Figure 5 include Totalpixels, indicating the total pixels processed, Cbcount, 

Ycount, Crcount and Acount, defined above, and Position, identifying the position, within the 
pixel of the component being output to the data stream by the decoder. 

At step 100 the variables are initialized. At steps 102, 110, 116 and 124, the position 
of the component within the pixel currently being decoded is evaluated. In this example, 
25 component Cb is in byte position zero of a pixel, component Y is in byte position one and 

four of a pixel, component Alpha is in position two and five of a pixel and component Cr is in 
byte position three of a pixel. Depending upon the position of the component in the pixel 
being output, at step 104, 1 12, 1 18 or 126 the count associated with the component at that 
position is compared against zero. If the count is zero, the bucket associated with that 
30 component is empty. Accordingly, at step 106, 114, 120 or 128 a process Get Next Encoded 
Block is executed and the encoded block is retrieved and decoded. The bucket associated 
with the component at the position being decoded is filled with the decoded values and the 
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associated count is updated. At steps 108, 1 16, 122 or 130 the component is output to the 
output data stream and the associated count is decremented. At step 132 the position and 
Totalpixels variables are incremented. At step 134, the Totalpixels/6 (i.e., the number of 
components in the pixel) is compared against the maximum number of pixels in the frame. If 
5 there are more components of pixels to decode, the process returns to step 102 and the process 
proceeds as described above. Otherwise, the decode process is complete. 

Figure 6 shows a flow diagram of one example of a process for implementing the Get 
Next Encoded Block processes 106, 1 14, 120 and 128 of Figure 5. For ease of explanation, 
the process of Figure 6 illustrates routines that may be used to map blocks encoded as Run, 

10 Ramp and Short Raw to component values. Modifications that may be made to this process 
for decoding other types of encoded blocks such as those listed in Table I will be readily 
apparent to one of skill in the art. At step 1 50, the first byte of data is extracted from the 
encoded block as N. As described in the above Table I, in one embodiment, the value of the 
first byte may be used to indicate the trend represented by the encoded block. At step 152, it 

15 is determined whether this value maps to a Run trend. If it does, then the extracted byte value 
is also indicative of the number of components in the run. Thus, the code sequence extracts 
the next byte value, and maps this value to the next N bucket locations of the component. 

If at step 1 52 the encoded block was not a Run code block, then at step 153 it is 
determined whether the value N indicates that the encoded block represents a trend is a Ramp. 

20 If so, at step 1 55 the next three bytes (indicating the starting value and two bytes of the slope 
of the ramp) are extracted from the encoded block. The procedure at step 155 is then invoked 
to build the ramp from the extracted components. 

If at step 152 it is determined that the encoded block is not a Ramp code block, at step 
156 it is determined whether it is a Short Raw code block. If so, at step 158, the number of 

25 raw values is determined, and a byte is extracted from the encoded block for each raw value. 

Applying the processes of Figures 5 and 6 to decode the set of encoded blocks in 
Table II will now be described with reference to the steps of Figure 5. When decoding begins, 
at step 102, Position equals zero, at step 104 Cbcount equals zero and therefore at step 106 the 
first encoded block is inferred to be a Cb type block. The Ramp is decoded and the Crcount is 

30 set to four. At step 108 the Cb value of '5' is output and Cbcount is decremented to three. 

At step 132, the position is incremented one. At steps 1 10 and 1 12, when position is 
equal to one, and Ycount is equal to zero, respectively, the next encoded block is inferred to 
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be a Y type encoded block. The block is decoded as a Run code block having six values of 
three. At step 1 14, the Y component value of *3* is output and Ycount is decremented to five. 

At step 132, the position is incremented to two. Thus, at steps 1 16-118, the Alpha 
bucket is determined to be empty, and therefore the next encoded block is decoded as an 
5 Alpha type, Short Raw block having three values of 1,0,1. At step 1 22, the Alpha type 
component value of ' V is output and the Acount is decremented to two. 

At step 1 32, the position is incremented to three. Thus, at steps 124-128, the Cr 
bucket is determined to be empty, and the next encoded block is decoded as a Cr type, Short 
Raw block having three values of 4,7,3. At step 130, the Cr type component value of *4 ! is 

10 output and the Crcount is decremented to two. 

At step 132, the position is incremented to four. The process proceeds to step 110, 
where it is determined that there is a Y component in the Y component bucket. At step 116, 
the Y component value of '3 1 is output, and the Ycount is decremented to four. At step 132, 
the position is again incremented to five. The process proceeds to step 1 16, where it is 

15 determined that there is a value in the Alpha component bucket. At step 122, the Alpha 
component is output from the bucket and Acount is decremented to one. 

The position value continues to increment, and components continue to be output 
from their buckets until the Alpha component bucket runs dry in the second pixel. Thus, the 
next encoded block is retrieved and inferred to be an Alpha type component, Short Raw of 

20 0,1 ,0. The '0' Alpha component is output to the output data stream and the process continues 
until all of the encoded blocks are decoded. The resulting, decoded data stream exactly 
matches the original data stream. 

In this method for compressing and decompressing a data stream using run length 
encoding techniques the compressed data may be reconstructed without any loss to data 

25 accuracy. The compression abilities of the method are further enhanced because no control 
data identifying the type encoded blocks are required. Rather, the encoder selects a 
component for encoding in response to a predetermined order of components in the original 
data stream and in response to the number of each of the components that have previously 
been encoded. The decoder infers the type of an encoded block based on the order of the 

30 encoded block and a series of encoded blocks, and based on the number of each of the 
components that have previously been decoded. 
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Although the above description has proceeded with regard to digitized video data, the 
described method is not limited to the transfer of any particular type of data. Rather, the 
techniques described above may be readily adapted by those of skill in the art to any data 
transfer, storage or processing application. 
5 Having now described a few embodiments of the invention, it should be apparent to 

those skilled in the art that the foregoing is merely illustrative and not limiting, having been 
presented by way of example only. Numerous modifications and other embodiments are 
within the scope of one of ordinary skill in the art and are contemplated as falling within the 
scope of the invention as defined by the appended claims and equivalents thereto. 



10 
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1 . A method of encoding a data stream comprising a repetitive series of a plurality of 
types of components, the method comprising the step of: 

selecting one of the types of components for encoding responsive to an order of the 
5 type of the component within the repetitive series, and responsive to a number of each of the 
types of components that have previously been encoded, wherein the number of each of the 
types of components that have previously been encoded varies according to identified trends 
in corresponding components of the associated type in the repetitive series. 

10 2. The method according to claim 1 , further comprising the step of: 

identifying a trend in corresponding components of the repetitive series; and 
encoding the corresponding components associated in the trend in a code block. 

3 . The method according to claim 1 , wherein the step of identifying the trend further 
15 comprises the step of identifying sequential corresponding components having the same 

value. 

4. The method according to claim 1 , wherein the step of identifying the trend further 
comprises the step of identifying sequential corresponding components having a value that 

20 varies linearly. 

5. The method according to claim 1, wherein the repetitive series of components 
comprise components of digitized video. 

25 6. A method of decoding a series of encoded blocks into a data stream comprising a 
repetitive series of a plurality of types of components, the method comprising the step of: 
associating an encoded block with one of the type of components in the repetitive 
series responsive to the position of the encoded block within the series of encoded blocks, and 
further responsive to a number of each of the components of each of the plurality of types that 

30 have been previously been decoded, wherein the number of each of the components that have 
previously been decoded may vary according to identified trends in corresponding 
components of the associated type in the repetitive series. 
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7. The method according to claim 6, wherein the step of associating further operates 
responsive to an order of components of data within the repetitive series. 

8. A method of encoding a stream of digitized video data comprising a series of pixels, 
5 each of the pixels comprising a plurality of ordered components, the method comprising the 

step of: 

selecting one of the components in the series of pixels for encoding responsive to an 
order of the component within the pixel, and responsive to a number of each of the 
components of each of the pixels that have been previously been encoded, wherein the 
10 number of each of the components that have previously been encoded varies according to 
identified trends in corresponding components of the series of pixels. 

9. A method of decoding a series of encoded blocks into a stream of digitized video data 
comprising a series of pixels, each of the pixels comprising a plurality of ordered components, 

15 the method comprising the steps of: 

associating each encoded block with one of the plurality of ordered components 
responsive to the order of the each encoded block within the series and responsive to a number 
of the plurality of ordered components that have been decoded, wherein the number of the 
plurality of ordered components may vary responsive to identified trends in corresponding 

20 components of the series of pixels. 

1 0. The method according to claim 9, wherein the step of associating further operates 
responsive to a predetermined order of the plurality of ordered components. 

25 11. The method according to claim 9, wherein the identified trends include a run trend 
where corresponding sequential components have a common value. 

12. The method according to claim 9, wherein the identified trends include a ramp trend 
where corresponding sequential components increase in value by a linear amount. 

30 

13. An encoder for encoding an input data stream comprised of a repetitive sequence of a 
plurality of types of components, the encoder comprising: 
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a counter for each one of the plurality of types of components, each counter for 
tracking a number of components of the associated type that are encoded by the encoder; and 

a selector, responsive to values of each of the counters and to an ordering convention 
of the sequence of the plurality of types of components, for selecting one of the types of 
components from the input data stream for encoding. 

14. A decoder for decoding a sequence of encoded blocks into an output data stream 
comprising a repetitive sequence of a plurality of types of components, the decoder 
comprising: 

a counter for each one of the plurality of types of components, each counter for 
tracking a number of components of the associated type that have been decoded but not output 
to the output data stream; 

a storage device for each one of the plurality of types of components, each storing 
device for storing components of the associated type that have been decoded but not output to 
the output data stream; 

decode logic for decoding each encoded block in the sequence into a component of 
one of the plurality of types of components; and 

select logic for selecting one of the plurality of decoded components to output to the 
output data stream in response to a value of each one of the counters and further responsive to 
a predetermined ordering convention of the output data stream. 

15. A system including a device for storing a sequence of encoded data blocks encoding a 
repetitive series of a plurality of types of components, the plurality of types of components 
having a predetermined order, the sequence of encoded data blocks comprising: 

a first plurality of encoded data blocks ordered responsive to the predetermined order 
of the series of the plurality of types of components; and 

a second plurality of encoded data blocks, each of the second plurality of encoded data 
blocks ordered responsive to a number of components encoded in previous encoded blocks 
encoding components of the same type and responsive to the predetermined order of the series 
of the plurality of types of components. 



16. 



The system according to claim 15, further comprising: 
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a decoder for decoding the sequence of encoded blocks into an output data stream 
comprising the repetitive series of the plurality of types of components, the decoder 
comprising: 

a counter for each one of the plurality of types of components, each counter for 
tracking a number of components of the associated type that have been decoded but 
not output to the output data stream; 

a storage device for each one of the plurality of types of components, each 
storing device for storing components of the associated type that have been decoded 
but not output to the output data stream; 

decode logic for decoding each encoded block in the sequence into a 
component of one of the plurality of types of components; and 

select logic for selecting one of the plurality of decoded components to output 
to the output data stream in response to a value of each one of the counters and further 
responsive to a predetermined ordering convention of the output data stream. 

1 7. An encoder for encoding an input data stream comprised of a repetitive sequence of a 
plurality of types of components, the encoder comprising: 

means for tracking a number of components of each of the types that are encoded by 
the encoder; and 

means, responsive to values of each of the counters and to an ordering convention of 
the sequence of the plurality of types of components, for selecting one of the types of 
components from the input data stream for encoding. 

18. A decoder for decoding a sequence of encoded blocks into an output data stream 
comprising a repetitive sequence of a plurality of types of components, the decoder 
comprising: 

means for tracking a number of components of each of the plurality of types that have 
been decoded but not output to the output data stream; 

means for storing components of the associated type that have been decoded but not 
output to the output data stream; 
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means for decoding each encoded block in the sequence into a component of one of 
the plurality of types of components; and 

means for selecting one of the plurality of decoded components to output to the output 
data stream in response to a value of each one of the counters and further responsive to a 
predetermined ordering convention of the output data stream. 

19. A storage device comprising: 

a sequence of encoded blocks, each of the encoded blocks consisting essentially of: 
an encoding indicator, indicating a type of encoding performed on the block; and 
at least one data field, wherein the encoded blocks in the sequence encode different 

ones of a plurality of types of components and wherein the type of component is not encoded 

in the block. 
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